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Importing Fixed-Field-Length Addresses 


By Joe Kroeger 

We ’ve discussed before in these pages the prob¬ 
lems of importing tab-delimited text files into 
address (and other) databases. But if the address 
information you are trying to import comes from a 
main-frame computer or from a PC, it can often be 
in a format different than tab-delimited. 

The purpose of any kind of database format, and 
there are several, is to define where the information 
destined for each field in a database is located in the 
incoming stream of data. Figure 1 (on page 2) shows 
the pop-up list of available export formats in File¬ 
Maker Pro. A database format describes (a) where a 
new record begins and (b) where a new field begins. 

A tab-delimited format says: (a) a new record is 
designated by a return character and (b) a new field 
is defined by a tab character. Commas can be used 
instead of tabs, but can cause confusion with com¬ 
mas that may be buried in the field data (there are 
ways to handle commas when needed). 
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Many fixed-field-length formats say that (a) a 
new record is designated by a return character and 
(b) a new field is defined by counting character loca¬ 
tions from the beginning of a record. In order to 
make this work, each record must contain the same 
number of total characters and an individual field 
must contain the same number of characters in every 
record. When the actual data for a field contains 
fewer characters than the number allotted by the 
format for that field, the remaining characters are 
spaces added to fill out to the correct count. 

One popular fixed-field-length format is called 
“DBF”. (See issue 40 of The FileMaker Report for 
more about DBF.) When exporting DBF data, File¬ 
Maker locates the longest actual data in the set being 
exported in order to decide how long the fixed field 
should be so that no data is truncated. On other ma¬ 
chines and with other software, the operator may 
establish the field lengths manually. 

FileMaker can both export and import DBF files, 
making importing very easy if you can acquire your 
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incoming addresses in the DBF format. An 
imported DBF file has the extra space charac¬ 
ters automatically stripped away - thus the 
fixed-length nature of the file is transparent to 
the user. 

However, sometimes data will arrive living 
in a simple text file with fixed-field-length 
records (and with returns between records), yet | 
without the proper header information and 

structure that identifies 
the file as DBF so that 

I 

FileMaker can import 
it transparently. Since 
such a file is not recog¬ 
nized by FileMaker as a 
DBF file, other mea¬ 
sures need to be taken 
to handle the import 
process. 1 


Field 

Length 

Name 

20 

Organization 

25 

Street 

25 

City 

20 

State 

2 

ZIP 

10 

Total 

102 


Let’s say you receive a text file with thou¬ 
sands of addresses in a fixed-field-length for¬ 
mat. You would like to import the data into 
your address database. You also receive a docu¬ 
ment along with the file indicating that the 
incoming data is arranged as shown in Figure 2 
for each record. 

If you open the text file using a word pro¬ 
cessor, the first few records might look like 
Figure 3 (the monospaced font makes the field 
counts clear). Notice that each field is filled out 
with spaces to the number of characters defined 
in the table in Figure 2. 

You might make a clone of your existing 
address database to try to import the data. But 
with no tabs (or commas) to define the fields 
and without the proper DBF format, FileMaker 
can’t make enough sense of the file to be able to 
put the data into individual fields, no matter 
which import format you try. 

As you might have guessed, I recently re¬ 
ceived just such a text file with fixed-length 
records. My first step was to add a new field to 
the clone to receive all the data destined for 
each record. I called the new field RawDataln. 
The data can then be imported as if it were in a 
tab-delimited text file. Steer all the data into 
this one new field. See Figure 4. 

Once the data is in FileMaker, we can create 
calculations to extract the field data and place it 
in appropriate individual fields. Until the need¬ 
ed calculations are all set up, I strongly suggest 
that only a few records be imported (see The 
FileMaker Report, issue 50, “Stupid FileMaker 
Mistakes”). 




/ r . 'M 


Making an importer File 

Since I had more than one incoming file to import and since I was planning to do the import process 
again in the future, I modified the clone of my address file so that it became a file to use just for importing 
fixed-length text information. The equations developed in this article are then retained in the Importer. 
My address files use separate FirstName and LastName fields but the incoming data has the whole name 
in one field (Figure 2), so I added a FullName field to use as an intermediate step. I also deleted several 
fields and calculations that would not be necessary for importation and would only slow things down. 


- & /> SSV. 
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Figure 3 


In order to extract just the 
data we need, an expanded version 
of the table in Figure 2 is useful. 

See Figure 5. 

The Place column in Figure 5 
shows the starting location of each 
field within each record. We’ll use 
that information to construct ex¬ 
traction equations. 

A calculation to put data into 
the FullName field is straightfor¬ 
ward enough - it just takes the 
left-most 20 characters from the 
RawDataln field. 

FullName = {text result} 

Left (RawDataln, 20) 

But when you examine the resulting data in 
the FullName field, you will notice that there 
are spaces to the right of the name characters in 
the field. These are the fill spaces generated at 
the origin of the data to make each field the 
same length. Fortunately, FileMaker has a built- 
in calculation function for just such eventuali¬ 
ties. Trim can remove the bounding spaces in a 
field without disturbing spaces between other 
characters. (By the way. Trim removes leading 
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Figure 4 


as well as trailing spaces. If you look up Trim in 
the FileMaker Pro manual, you should proba¬ 
bly ignore the second and third examples - they 
don’t seem to make sense.) Adding Trim to the 
equation makes it look like: 

FullName = {text result} 

Trim (Left (RawDataln, 20)) 


Organization = {text result} 

Trim (Middle (RawDataln, 21, 25)) 


City 20 71 

State 2 91 



This calculation pulls out 25 characters 
from RawDataln starting at the 21st character 
in the field, omits any bounding spaces and 
plops what is left into the Organization field. 


Specify field order for import 


Data in: "NewAddrA .txt" Fields in: " Addr Importer" 


JOHN DOE HAPPY PLAY SCHOOL ... 

-► 

RawDataln 

o 



FirstHame 




LastName 




Organization 




Location 




Street 




City 




State 




ZIpText 




NewRecordDate 




NameCode 

!• • 



Temp A 

: 



TempB 

<> 


□ Scan Data 0 R * cord 1 [ cancel ) 


® Rdd new records 
O Replace data in current found set 



This version works fine. 

Extracting information from RawDataln 
for the Organization field is similar. But since 
the information is coming from the middle of 
the data this time, we use the Middle function 
instead of Left. 
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The Street, City, State and ZIP field calcula- 

tions are similar. 


Street = 

{text result} 

Trim (Middle (RawDataln, 46, 25)) 


City = 

{text result} 

Trim (Middle (RawDataln, 71, 20)) 


State = 

{text result} 

Middle (RawDataln, 91, 2) 


ZIP = 

{text result} 

Trim (Middle (RawDataln, 93, 10)) 



Trim is not really needed in the State calcu¬ 
lation since the allocated space is only two 
characters to start with so there are no spaces to 
trim. And remember that the ZIP field should 
always have a text result, not a numeric result. 

Once all the calculations were entered and 
debugged on trial data, the next step was to 
import all the real data. In my case I had four 
large text files with about 10,000 records each, 


so I deleted the trial data and made copies of 
the Importer A file, naming them Importer B, 
Importer C and Importer D. Then I imported 
all the data. 

There are a few sanity checks that are worth 
running. If there is something wrong with the 
character counts in the text file input, the data 
in the individual fields will shift. A View Index 
on the State field will show mildly offset data. 
Finding empty State fields can also be revealing. 
Looking at the ZIP field may reveal a glitch. In 
my case I knew that there was supposed to be a 
name of an individual person in each record, so 
I could Find for an empty FullName field. 

All went reasonably well and I had man¬ 
aged to capture data from a fixed-field-length 
text file. With most of the data located in their 
usual fields, I could then move addresses to my 
various address files and perform my normal 
data validation routines. The only thing miss¬ 
ing: I wanted to split the FullName field into 
FName and LName fields. That is the subject of 
the following article. 


Extracting First and Last Names from Full Names 


By Joe Kroeger 

An old and recurring FileMaker problem is 
to separate the first name and last name infor¬ 
mation from a field containing the full name. 

The previous article in this issue describes a 
situation where such an extraction is needed. 

| 

There have been several methods described | 
in these pages over the years for accomplishing 
this task. This article discusses an additional 
approach using a good general technique that 
will help with other problems as well. 

The Setup 

• An Address file contains several thousand 


addresses. (The problem is trivial if there are 
only a couple of dozen records since it would 
be easier to do the extraction manually.) 

• A text field called FullName contains the full 
name of the addressee. 

• New text fields called FName and LName 
have been created and they are currently empty. 

• FullName has been trimmed so there are no 
leading or trailing spaces to worry about. 

• FullName contains a name in every record. 

• FullName contains at least one space in each 
record. 

Any extraction technique like this one de¬ 
pends to a great extent on the assumed format/ 
content of the field from which items are to be 
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separated. It pays to write down the assump¬ 
tions and to be clear about both the content 
and any exceptions. Our basic approach in¬ 
volves locating spaces in the FulIName field 
data and using them to decide where and what 
to extract. Thus we need to be clear about the 
occurrences of spaces in the FulIName field 


and what they mean. 

If the first name and the last name are 
always one word each, the FulIName field will 
contain only one space and the problem is 
greatly simplified. We just detect the position of 
the space and use it to divide the data into first 
and last names. 


tm 


Options for Field “FName” 


Operators 


Functions 


Prefix 

First Name 

<> 

0000® 

* 


Last Name 

Organization 

■ 

00 00© 

> 

< 


Location 

Street 


0000® 

2 

L 

|| 

City 

State 

% 

(<>)M( 0 lu) 

and 

or 

1 


Abs (number) 

Atan (number) 

Average (repeating field] 
Cos (number) 

Count (repeating field) 
Date (month, day, year) 
DateToText (date) 

Day (date)_ 


Left (Last Name, Position (Last Name, ” ”, 1))| 


Calculation result is |Te»t 
□ Repeating field with a maximum of 


ualues 


[ Cancel ] 

C ° k J 


Entering a FileMaker Equation: a Cookbook 

For those inexperienced with 
building FileMaker equations, try 
these steps to put together the 
FName calculation described in 
the article. 

• Choose the Define Fields com¬ 
mand from the Select menu. 

• In the resulting dialog box, type 
“FName” as the name of the new 
field being created. 

• Specify the field type as “Calcula¬ 
tion” using the radio buttons at 
the lower left of the dialog box. 

• Click on the Create button. This 
brings up the equation definition dialog box where the components of the equation are assembled. 

• Use the pop-up list near the bottom of the box to specify that the result of the calculation is to be Text. 

• Scroll through the function list in the upper right corner to locate the Left function. Double click it. This 
puts the Left function and surrogates for its parameters in the center section of the dialog where the cal¬ 
culation is being assembled. Double-click on the first parameter (“text”) to highlight it. 

• Scroll through the list of fields in the upper left corner to locate the FulIName field. Double-click it to 
place FulIName into the calculation as the first parameter. 

• Double click the next parameter (“number”) to highlight it. 

• Scroll through the upper right list again to locate the Position function. Double-click it. Position and its 
surrogate parameters are added to the calculation. 

• Double-click the first parameter of the Position function (“text”). 

• Scroll through the upper left list to locate FulIName again. Double-click it. 

• Double-click the next parameter (“search string”) and click the button in the upper center area that 
contains double quotes. Note that the cursor ends up between the quote marks. Type a space. 

• Double-click the next parameter (“start”) and type a 1. The proper number of parentheses will have 
been created for you. 

• Click the OK button. If all goes well click the Done button in the next dialog. The equation will be evalu¬ 
ated for all the records in the database. 

• If a problem is detected, FileMaker presents a diagnostic dialog that will help fix the equation. 
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Simple First Name 

Start with an equation like this to extract 
the first name: 


FName = {text result} 

Left (FullName, Position (FullName " A ", 1)) 

(Note: the A character in our printed equations 
indicates where a space should be entered. 
Don’t enter the A but type a space bar instead.) 

The Position function generates a number 
that indicates, individually in each record, how 
many characters there are from the left of the 
field to the first space. This is (almost) the 
number needed by the Left function to specify 
how many characters are to be extracted. 

If the calculation is implemented as above, 
however, not only is the first name extracted, 
but the space following the first name as well. 
We need to take one less character. Subtracting 
1 from the Position result makes the calcula¬ 
tion look like this: 

FName = {text result} 

Left (FullName, Position (FullName “ A ", 1)-1) 

This equation works well, given the assumption 
of a single space. 


Simple Last Name 

A similar calculation works to extract the 
last name. Since we are pulling from the right 
side of the field this time, we need to subtract 
the Position value from the total length of the 
field to know how many characters the Right 
function will pull out. 

LName = {text result} 

Right (FullName, (Length (FullName) - 
Position (FullName, " A ", 1))) 

This works well, given the assumption of a sin¬ 
gle space. An alternative approach is to use the 
Middle function to extract data from the loca¬ 
tion of the first-space-plus-one to the end of 
the FullName field. 


Complications 

If the contents of the FullName field don’t 
meet the simplifying assumption, life gets more 
complex. If there are more spaces in the field 
than one, the calculations need to take that into 
account. How might this situation arise? Some 
records might have “DR” or “PROF” before the 
first name. Some last names like “DE ANGELO” 
contain internal spaces. Some records might 
include middle initials. Sometimes a suffix like 
“JR” or “MD” is appended to the last name. 

In my address files I like to (a) keep prefixes 
in a separate field, (b) eliminate middle initials, 
(c) convert spaces within the last name to hard 
spaces, and (d) keep suffixes in the last name 
field. You might devise a different set of rules. 

While it may be possible to build a set of 
equations to cover all the eventualities, that can 
be a lot of work. My philosophy is to try to cov¬ 
er with calculations most of the combinations 
that arise, then deal with the remaining records 
separately. You might, for example, Find all 
records with “=DR” in the FullName field. If 
there are only a few, deal with them manually 
so that those records then fit the mold for your 
extraction calculations. (You might decide not 
to retain “DR” at all, so just delete those char¬ 
acters. Or you might add “DR” to a separate 
Prefix field and then delete from FullName.) 
Even if there are more than a few such records, 
it may pay to create a new clone of your work¬ 
ing file, import into it all the “DR” records, 
then build custom calculations to handle them. 

Nesting Position Functions 

Since there are typically a mixture of records 
with one space and more than one space in 
FullName, I thought it might be useful to de¬ 
tect the difference. I was already using the Posi¬ 
tion function to spot the location of the first 
space. What I wanted was a way to decide if any 
spaces exist after the first one. Could Position 
be brought into service again, possibly nested 
into the same equation? I tried this: 
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FullNameSpaces = {numeric result} 

Position (FullName, " A ", Position (FullName, 

" A ", 1) +1) I 

I 

The Position function conveniently in- | 

I 

eludes a parameter that allows you to specify at 
which character location Position will start 
looking for the target text. (Thank you Claris!) 

I simply inserted another Position function as 

^ I 

that parameter to figure out where the first 
space is, then added 1 to it. 

Note that the result in FullNameSpaces is 
not the number of spaces in the field. Instead, 
the value is zero if there is one space in the 

1 

field, and greater than zero if there are multiple 
spaces. In addition to being used with a Find 
command, FullNameSpaces might also be in¬ 
cluded in another calculation as a way to make 
a decision based on the existence of multiple 
spaces in FullName. I 

Many instances of multiple spaces can be 
handled with the nested Position function 
technique like the one in the previous equation. 

To illustrate this technique, we’ll build such an 
equation for extracting last name information. 

The same type of approach can be applied to 
the first name if desired. 

| 

| 

Complex Last Name 

When there are multiple spaces in Full- 
Name, the extra ones are often embedded in 

I 

the last name information; suffixes seem to 

£ 

occur much more often than prefixes. If a large 
fraction of your records have middle initials, 
which will affect the last name extraction, it will | 
be important to devise a method for eliminat¬ 
ing them. Perhaps a FullName2 field derived 
from FullName but with middle initials elimi¬ 
nated would help. On the other hand, if you 
have a lot of names with suffixes, a different 
strategy may work better. 

The following LName calculation is a par- j 
tial solution. It detects the presence of a single J 

space in the FullName field and in that case | 


falls back to the simple equation shown earlier. 
When more than one space is detected, the 
calculation extracts everything after the second 
one. If you can arrange for there to be no last 
names with internal spaces, the result is that the 
equation breaks down only for each of these 
two combinations: 

• there is a prefix and a middle initial, with or 
without a suffix; 

• there is a suffix with no prefix and no middle 
initial. 

LName = {text result} 

Right (FullName, (Length (FullName) - (If 
(Position (FullName, ,<A ", Position (FullName, 
,,A ", 1) + 1) = 0, Position (FullName, ,,A \ 1), 
Position (FullName, ,,A '', Position (FullName, 
" A “, 1 ) + 1 ))))) 

This calculation may look complicated, but 
is pretty straightforward when broken down 
into component pieces. Perhaps it will help to 
just trace through the Position functions in 
sequence and see what each is accomplishing. 

We want to take the right-most number of 
characters determined by subtracting a value 
from the number of characters in the whole 
field. The first Position is used in an If function 
in conjunction with the second Position to 
detect if more than one space is present. The 
second Position checks for a second space and 
if there isn’t one (if the If condition = 0), the 
value returned by the third Position (the loca¬ 
tion of the first space) is what is subtracted. 

One the other hand, if more than one space is 
present, the fourth and fifth Position functions 
work together to return the location of the sec¬ 
ond space for subtraction. 

Whew. Use it and enjoy. 

♦V- 
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Figure 1 


Structured Development of FileMaker Solutions 


By John Coon 

FileMaker pro brings many of the best char¬ 
acteristics of the intuitive Macintosh interface 
philosophy right into the working application 
level, making the learning process easy and the 
development process simple. In many cases, 
developing a template or application is almost 
automatic: you just start “doing ” FileMaker 
and the program evolves into existence. File¬ 
Maker Pro allows for incredibly fast develop¬ 
ment and prototyping; this “quick out of the 
blocks” approach sometimes can be assisted by 
pre-development task and data analysis. “Fields 
and Files Definer” (hereinafter called “FFD”) is 
a FileMaker template that helps in the planning 
stages of file development; it is a method of 
“structured design for free-form programming”, 
if that is not too much of a contradiction. 

Template design begins with an examina¬ 
tion of three topics: 

• Understanding the User’s Needs - the 
beginning of files development; involves re- 


File Edit Select Layout fhrantje Format Scripts Window 


search, interviews and review of existing soft¬ 
ware, if any; determines “how/where/when/why 
and by whom” the software will be used. 

• Examining the Data - the beginning of 
fields development; what data is needed, what 
exists electronically, on paper or in mysterious 
“shoe box” mode. What data fields are required 
for information, what fields are required to 
trigger lookups, calculations and summaries? 

• Qualifying the Resources - the beginning 
of a development plan; what needs to be done, 
who is suited to the tasks; what is the quality 
and quantity of the data; when must data entry 
or reconciliation begin? 


Layout *1 



Records: 
300 


File Name 
Field Name 
Field Num 
Field Type 
Purpose 
Lookup From List 
Lookin To List 
Record Nun 
Record Date 
Field Nane Count 
All Rees Blank 
Sample Data 


01 92 Enrolled Base Cows Yearly 
B WT 

i o I. 


Herd Mast 
Ancestry 
Acct Nums 


liooLUBl 


Structured Design Avoids Redesign 

File definitions, file names, field definitions 
and field names need to be carefully thought 
out so they address the problem and communi¬ 
cate well to both the developer and the user. 
Consistency and sanity in naming files is a good 
beginning. By the time an application has been 
“scripted, buttoned and looked-up”, changes to 
file and field names be- 

i come a major headache. 
Window ^ , , , 

. ——1 Pro 2.0 s expanded capa- 

bilities (such as inter-file 
|j| scripting) and fine-tuning 

.. 1 (such as enhanced Replace 

™1 choices and Preferences) 

make “pre-planning” vi¬ 
tal. Complex templates 

_ usually have enough fields 

. III! to make importing, ex- 

======= !| porting and looking up 

— data between FileMaker 

Pro files more than once 
quite tedious. Why suffer 
s through all this? 

<> “Fields and Files De- 

IQ B finer” is a reborn dinosaur 
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of a FileMaker 4 template (circa 1987-88) 
originally developed to provide relief from 
that early version’s inability to sort field 
definitions. The issue was resolved when 
Claris released FileMaker Pro, but was, to 
me anyway, unacceptable as I lost concen¬ 
tration and attention when having to “sort 
and search” for fields while editing field 
definitions. I created FFD so I could build a 
model of a template prior to beginning the 
actual development. Figure 1 shows an FFD 
layout. Data entry can be automatic or not. 

The fields File Name, Field Name, File 
Type, Sample Data, Lookup From List and 
Lookln To List allow you to enter and modify 
proposed file and field names, sort them and 
produce lists that are invaluable when import¬ 
ing data or entering definitions of fields. 

Figure 2 is a different FFD layout showing a 
list of files and fields. Formulas for calculations 
or notes for summary fields can be entered in 
the FFD Sample Data field. 

Pre-planning of lookups between files can 
save a lot of anguish resetting look-ups. If you 
don’t need to change filej names or field names, 
you won’t often need to change the look-up 
definitions. FFD includes fields to anticipate 
and display when information is looked-up- 
from another file and when each field is 
looked-into by other files. The usefulness of 
pre-planning of look-ups has become even 
more helpful when using inter-file scripting 
now available in Pro 2. 

Figure 3 is an FFD summary of lookup 
linkages. Lookup file names are set in field defi¬ 
nitions, formatted as check boxes. 

I found that templates developed using the 
FFD tool as a planning aid generally were better 
throughout, required fewer changes and were 
completed more quickly. Debugging time was 
also improved. 

Design Example: Cattle Herd Management 

A recent project involved a cattle rancher’s 


File Name Field Name Field Tu ne Sample Data Lookup From Loolcin To 


12 Fullblood 

Cow Born 

Text 

nnn, text. 


Ancestry 

04 F1 Females 

DOB 

Number 

1973 


Aoct Nums 

06 First Cross 

DOB 

Text 

text, dates, 


Acct Nums 

07 First Cross 

DOB 

Text 

nnn, text. 


Acct Nums 

08 Fullblood 

DOB 

Date 

date, blank 


Acct Nums 

09 Fullblood 

Date of Birth 

blank 

blank 

Herd Mast 


10 Fullblood 

Date of Birth 

blank 

blank 

Herd Mast 


11 Fullblood 

Date of Birth 

Text 

text, blank 

Herd Mast 


14 Purebred 

Date of Birth 

Date 

date, blank 

Herd Mast 


01 92 Enrolled 

DOB 

Number 

1987,86, 



02 Enrolled 

DOB 

Number 

1987, blank 

Herd Mast 


03 Enrolled 

DOB 

Number 

1987,blank 

Herd Mast 


05 First Cross 

DOB 

Date 

date, blank 

Herd Mast 



Figure 2 
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□ Ancestry 
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LUFrom: 

LUTo: 

0 Herd Mast 
□ Herd Mast 

□ Ancestry 

□ Ancestry 

D Acct Nums 
0 Acct Nums 


DOB 

LUFrom: 

LUTo: 

0 Herd Mast 
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□ Acct Nums 
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Figure 3 


need to keep track of the 1000-plus cows and 
bulls in the ranch herd. The main file is called 
Herd Master. The cattle were being raised as 
breeding animals, so it was important to main¬ 
tain breeding and birthing performance, health, 
and physical data for each animal. 

Lineage history was the other key require¬ 
ment. Three generations of breeding are re¬ 
quired to produce a purebred from scratch; 
since most of the base cows are bought without 
significant lineage information, the database 
could take several years to “beef up” (sorry) 
with actual data. 

Figure 4 shows hierarchical lookups for 
lineage data. Each generation is looked up from 
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its off-spring; calf data is stored in repeating 
fields. 

Since an animal’s commercial value is based 
on growth performance and lineage, we needed 
to create a template that would manage both 
tasks with one set of data. The ranch manager 
had previously kept the cow’s records in three 
ways: (1) herd totals were taken from paper 
records and reports were prepared in Excel; (2) 
15 different Microsoft Works files were used for 
inventory and other purposes; (3) there was 
lots of data still stored in actual shoe boxes and 
shoe box substitutes. 

The Works files had names like Enrolled 
Base Cows and Enrolled Base Cows 1992, but 
the ranch manager could not reliably tell what 
was what. Whenever the ranch lawyers or ac¬ 
countants needed information, the manager 
would create a new version of the Works file, 
update and edit the data and produce a report. 


_ Cattle in LUorks Files _ 

15 items 48.2 MB in disk 26.8 MB av 


@01 92 ENROLLED BASE COWS YEAR... 
@02 ENROLLED BASE COWS 
@03 ENROLLED BASE COWS YEARLY 
04 FI FEMALES 
@05 FIRST CROSS BULLS 
@06 FIRST CROSS FEMALES 
@07 FIRST CROSS FEMALES 1992 
@08 FULLBL00D BULLS 


I®09 FULLBLOOD CALVES 1988 
@ 10 FULLBLOOD CALVES 1989 
@11 FULLBLOOD FEMALES 
@ 12 FULLBLOOD FEMALES 1 992 
@ 13 PUREBRED BULLS 
@ 14 PUREBRED FEMALES 
@16 YEARLY....ENROLLED BASE COWS 


Many files had the same records but with 
slightly different data; the data never conflicted 
from file to file, but often was supplemented by 
other fields with additional data in them. 

Again, the manager could not determine the 
differences between - or the recency of - one 
file over another. He did good work with the 
limited tools available. My job was to make it 
easier for him to do even better work. 

Appending a better description or number 
to the Works file names helped keep records 
distinct for importing into FileMaker (as shown 
in Figure 5). 

The Conversion Challenge 

I had to wind up with “about 1000” good 
head of cattle from 15 different files; in total, 
more than 3000 records had to be examined 
and merged or discarded. The issues I faced for 
determining how to best combine and convert 
the data from Works were maddening: 

• There wasn’t a unique ID field for each 
animal! Sometimes the animal was identified in 
differing fields, like “Cow Number”, at other 
times in “Bull Number”, “Dam Number”, 
“Herd Number” and even “Calf Number.” 

Each animal in the herd had a two-part brand 
on it comprised of “year” and “serial number”; 
but there were four different numbering sys¬ 
tems, each inherited from the prior owner of 
the cattle, and each system made its own kind 
of internal sense. As a result, there were some- 
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times different records with the same ID’s since 
the animals had been obtained from various 
sources. j 

• In comparing data between files, there 
were lots of “near duplicate” records and files 
with no data in many of the fields. A truly 
amazing variety of data were entered into date 
fields. 

• There was no logical or apparent distinc¬ 
tion between generations of animals. 

• There was no consistency in field names 
between the 15 files. For example, the field 
names for a cow’s date of birth included 
“DOB”, “D O B ”, “Date of Birth” and, my 
favorite, “Cow Born”! Different names were 
used for the same data, sometimes for the same 
animal. See Figures 6 and 7. 

Somehow or other, I needed to bring all 
these records together into one FileMaker file 
so that the separate data elements from each 
animal’s histories could be merged into one 
consistent, concise record per animal. This was 
a fun project. Really. 

| 

To Look-Up or To Import, 

That is the Question... 

One approach was to create a series of elab- 1 
orate lookups based upon a matching field and | 
then spin-off other look-ups from there. The 
benefit of this approach would be the creation 
of fewer duplicate records, but the 


iDetali of Field Names in RCR Fields 


DOB 

01 92 Enrolled Base 

DOB 

02 Enrolled Base Cows 

DOB 

03 Enrolled Base Cows 

DOB 

04 FI Females 

DOB 

05 First Cross Bulls 

DOB 

06 First Cross Females 

DOB 

07 First Cross 

DOB 

08 Fullblood Bulls 

Date of Birth 

09 Fullblood Calves 

Date of Birth 

10 Fullblood Calves 

Date of Birth 

11 Fullblood Females 

Cow Born 

12 Fullblood Females 

DOB 

13 Purebred Bulls 

Date of Birth 

14 Purebred Females 


with the intimate knowledge of the sex lives of a 
thousand bulls and cows over the past three 
years could decipher the differences. In order to 
organize the data and minimize the unneces¬ 
sary BS (sorry again!), I used FFD to examine 
the data and pre-plan the import. 

Fields and Files Definer To The Rescue! 

In truth, the process of defining the data 
contained in each Works file was made much 
easier by having two computers: on a Power- 
Book, I had the Works files open to examine as 
I entered data into FFD on my desktop Macin¬ 
tosh. The file name field in FFD was set up for 
auto-entry; for clarity, I appended a 2 digit 
number to the name of the Works file. The field 
names were entered and the Works records 
were examined for data; where none existed, 


data was too vague to be reliable. 
If the ranch manager had been 
able to identify which of several 
records for the same animal was 
considered the “master”, this 
approach might have worked. 

The alternative, and the 
method finally employed, was to 
import the data from all the files 
into Herd Master, resolve as 
much data as I could, and get the 
manager started earlier on recon¬ 
ciling the data since only a person 
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the field was coded (in FFD) as “blank”. Why 
import entire fields of nothing? Field types and 
a list of look-up files were chosen from a pop¬ 
up list or were formatted as check boxes. After 
entering the data representing the various 
Works files, I printed detail reports of the field 
names. 

Next, I omitted the fields that had been 
coded as “blank” and contained no data. The 
detail reports shrank considerably; while there 
were a lot of files and fields, there wasn’t a huge 
amount of data. From final summary reports, I 
had a complete list of all the fields that needed 
to be imported from all the different files. From 
this list, I could begin defining the field names 
in Herd Master. Figure 8 shows the result of 
omitting fields that contained no data. 

The final aspect of using FFD was to pro¬ 
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duce a check-off list to assist during the multi¬ 
file import into Herd Master. This was done by 
omitting the “blank” fields and sorting by the 
“original sequence” in the Works file within the 
file name. See Figure 9. This list saved a lot of 
time during the import order setup; because 
the incoming data differed from file to file, it 
didn’t make sense to use a script to “freeze and 
restore” the import fields dialog. Sample data 
was helpful in previewing records before im¬ 
porting. 

Following each file’s import, I used Replace 
commands to fill in other identifying fields 
(Source of Data, for example). After the last file 
was imported, the ranch manager used various 
combinations of Find commands to compare 
records and consolidate each animal’s data into 
a single record. 

Ready! Set! Import! 

All the work described above prior to actu¬ 
ally performing the import may seem unneces¬ 
sary; after all, FileMaker Pro is a “just do it!” 
application! However, in cases like this, the 
front-end overhead is well worth the time. 

Once the data is imported, it is vital that it be 
understood in terms of both quantity and qual¬ 
ity. It is beyond the simple “Garbage In = Gar¬ 
bage Out” notion; once the files are merged, the 
data needs to be reconciled and modified to 

make sense within a database. 
FileMaker Pro is an excellent 
environment for this - lay¬ 
outs, for example, can be im¬ 
plemented quickly for a 
specific purpose, used, modi¬ 
fied and discarded. 

The benefit of the struc¬ 
tured approach during im¬ 
ports and conversions is in 
providing a high level of con¬ 
fidence during the import 
cycle. FileMaker’s importing 
flexibility for “field to field” 
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correspondence when field names do not 
match is essential for tasks like this, but field 
alignment in the import dialog process is not 
the best time to be caught second-guessing 
what’s in the various import files. 

Having the printed list of the fields in each 
file to be imported kept the import process 
under control. Since I was merging all of the 
variations of “Date of Birth” into one field stor¬ 
ing the animal’s birth date, the list of fields 


being imported was invaluable. 

The depth of examination of the data nec¬ 
essary to produce a FFD for the Herd Master 
project required a detailed look at the quality of 
the data. It was important to get the ranch 
manager to acknowledge the state of the data 
being imported and the need to begin immedi¬ 
ate reconciliation of the files. With FileMaker 
Pro, the manager used a variety of layouts to 
speed up his work. The conversion of the data 
was done using Replace operations on found 
sets and, most interestingly, in creating scripts 
that semi-automated data entry or modifica¬ 
tion on a record by record basis. 

On a project level, the pre-planning and 
data examination helped in building the correct 
file structure and fields to meet all information 
needs. With a “just do it” approach, many of 
the data connections and conditions may not 
always be known, much less understood. 

With any template, a basic question needs 
to be answered: “What is a Record?”. If you get 
the answer right, the development will likely go 
well, however convoluted the existing records 
or procedures may be. FFD helps you get orga¬ 
nized in advance of just doing it. 


Wonderful Sources of Data 

Users keep data in unusual and wonderful places - the shoe box is the classic example. A closet of 
partially-full shoe boxes of little slips of paper, with dates on the ends of some of the boxes. Grocery bags 
and desk drawers can serve as the same type of repository. While it often makes sense to the person doing 
the filing, it is sometimes frustrating for an outsider to try to extract information to help organize the data. 

For example, I asked “How do you know this animal is a Yearling Bull Angus ? There s no birth date 
or breed type in the record.” 

“Because I bought it from Ed last January... right after the winter calving.” 

“There is nothing in his paper work that says so. How do I know that?” 

“Well, everyone knows Ed only raises Angus and only sells bull calves. And I only bought from Ed 
once last year...” 
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6> Alphabetic Page Breaks 


By S. C. Kim Hunter 
Acropolis Software 

Page breaks are created in FileMaker with 
sub-summary parts on layouts. When adding a 
sub-summary part to a layout, one field must 
be selected as the basis of the sub-summary, 
and a page break can be made to occur when¬ 
ever the value in the selected field changes. 

Ideally, some field that already exists in the 
database can be used to implement the page 
break, but often there is no field that exactly 
fills the bill. For example, suppose you have a 
text field of dictionary words and you would 
like to design a layout to print the words so that 
all those starting with A’s are on one page, with 
B’s on the next, and so forth. 

If you create a sub-summary based on the 
word field, page breaks will occur for every 


record - obviously not desired. Before adding 
the sub-summary to the layout, create a new 
field, named, for example, FirstLetter. Define 
the field as a calculation and enter the following 
equation: 

FirstLetter = Left (Word, 1) 

Word is the field containing the dictionary words. 

This calculation extracts just the first (left¬ 
most) letter of Word into the FirstLetter field. 
Create the sub-summary to be based on sorting 
by the FirstLetter field and click the button 
Page break after every 1 occurrences. 

When sorted by the FirstLetter field, print¬ 
ing will place each set of words for each first 
letter on a new page. If one set takes more than 
one page, the list will flow over to additional 
pages then break for the next letter. 

* J \r* 


FileMaker Quick Tips & Techniques 


By Joe Kroeger 

Close Hidden Files from the Keyboard 

The FileMaker Windows menu shows not 
only open and visible files, but also files that are 
open and not visible. This makes it easy to nav- | 
igate among open files. Open files that are not 
visible have parentheses around their names. 

The currently active (top-most) and visible file 
is indicated with a check mark. 

When finished working with a complex file 
that has, say, five associated lookups, it takes a 
little work to close them all so that you can 
move on to another project. You can select 
each individual invisible file using the mouse in 
the Windows menu and then either click the 


go-away box or type command-w to close the 
file. But there is another method that I have not 
found documented anywhere. Command-w 
works to close the active window and also clos¬ 
es invisible windows when no more visible files 
are open. If you just keep typing command-w, 
you will sequentially close all open windows, 
even those that are hidden. It is not necessary 
to use the Windows menu to first make a file 
visible. Nice little time saver. 

Not "Quark Express" 

In issue #51 the article on database publish¬ 
ing referred in a couple of places to the Quark¬ 
XPress layout program, but did not always spell 
it correctly. It should be QuarkXPress. 
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Errata: POSTNET equation bug 

In The FileMaker Report, issue 51, page 10, 
the formula for the postnet check digit pro¬ 
duces an answer of “10” when the zipsum ends 
in 0. The correct value must be only one digit 
and should be “0” for zipsum = 0. Try this 
equation instead: 

CheckDigit = {text result} 

Right (10 - Right (zipsum, 1), 1) 

(from S. C. Kim Hunter) 

Recommended Reading 

The September issue of MacUser magazine 
has an article on page 249 called “Double-Duty 
Databases” by Gregory Wasson. It concerns 
sharing FileMaker databases in a mixed Win¬ 
dows and Macintosh environment and includes 
a series of suggestions for designing databases 
to be shared. 

Future Diskettes 

Apple has announced that they will move in 
future machines (perhaps in 1994) to diskette 
drives that will not support 800K diskettes. This 
is evidently a cost-saving decision and may 
include use of drives that require manual ejec¬ 
tion of the diskette, at least on low-end models. 
Will we need to buy only 1440 HD diskettes in 
the future? Not clear - it may be that Apple will 
handle the lower density diskettes by reformat¬ 
ting them to 720K. 

Accidental Deletion of Records 

I received two additional recent reports 
from FileMaker users about unintended dele¬ 
tions of groups of records. One poor soul 
thought he had found a set to delete, but he had 
in fact done a Find All and then selected Delete 
Found Set. (Imagine sitting there helplessly 
watching all your data disappear!) 

If you realize soon enough that you made a 
delete mistake, it might be possible to restart 
the machine and then try to recover informa¬ 


tion from the (damaged) file. This qualifies as a 
corollary of the GAS premise (Grasping At 
Straws) and is not suggested. Another GAS is to 
pull out a disk block editor program and try to 
extract the data from sectors of your hard disk. 
Also not suggested. 

There is no command or technique avail¬ 
able to directly undo a delete operation. I know 
of only three ways to proceed in this kind of 
situation: (1) get along without the data; (2) 
recreate the data; (3) replace the file with the 
most recent backup. (A fourth method is actu¬ 
ally a cop-out: quit your job.) 

In some cases recreating the data can be 
easy - perhaps the file you were working on is 
used only for quarterly reports and drew its 
data from a separate master file. 

Often the best procedure can also be the 
easiest one: retrieve a backed-up version of the 
file. But if, as in the example above, the latest 
backup is six months old, this approach won’t 
help much. 

Which brings up a great Stupid FileMaker 
Mistake to add to those in issue #50: Don’t 
Make Backups! **, 




tamffstftmmim 


Address Changes 

Keeping track of address changes for subscribers is an 
important on-going task here. Many thanks to all of 
you who let us know ahead of time that you are mov¬ 
ing. But some subscribers neglect to tell us and their 
issues come back to us and need to be remailed if we 
can ferret out a new destination. Extra delay and ex¬ 
penses are the results. Please, please notify us before 
you move. 

New Numbers 

Most of you by now have registered our new phone 
numbers: 

voice: 408-726-1232 
fax: 408-726-1233 

But still buried in a few phone databases are the old 
numbers lurking about. Please make the changes. 
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